Fixes mendixlabs/mxcli#758 and the root cause in #765.

Problem

Mendix models inheritance across multiple tables: a child adds attributes to the parent's, and all of the parent's are members of the child. An access rule must therefore carry a MemberAccess entry for every member — own and inherited — or Mendix reports CE0066 "Entity access is out of date".

Both the GRANT builder and ReconcileMemberAccesses enumerated only entity.Attributes. Two consequences, and the second explains why the first couldn't be worked around:

• GRANT naming an inherited member produced no entry at all, while reporting success.
• Reconciliation runs immediately after every GRANT, and on any write touching the module. An inherited reference is qualified against the entity that declares it, so it never matched the child's own attribute list and was deleted as stale — removing, in the same command, what the grant had just written correctly.

That last point is the whole issue: it is why REVOKE + GRANT never repaired a damaged rule, and it is not visible from the grant code alone.

The damage was masked. mx check reports CE0066 and stops, hiding the CE2729 "No read access to attribute" cascade until Studio Pro's Update security is clicked — so CLI-only workflows shipped it undetected.

Two facts, established against mx check rather than inferred

1. An inherited reference is qualified against its declaring entity.

This is the same rule the change-object writer needs (mendixlabs#451).

2. System.User is the exception. Entities specialising it are user entities whose platform members Mendix manages:

Verified on Mendix's own Administration.Account and on a fresh specialisation, with a no-op-rewrite control confirming that merely touching the module doesn't itself trigger CE0066.

Approach

• EntityMembers (new, mdl/executor/entity_hierarchy.go) walks the generalization chain, qualifies each member against its declaring entity, handles child-shadows-ancestor, guards against cycles, and excludes System.User's platform members.
• The GRANT builder uses it, and now rejects a named member that matched nothing instead of dropping it silently — the behaviour that made the bug unrepairable.
• Reconciliation strips only a reference qualified to the entity itself. An ancestor may live in another module or in System, neither of which is loaded at that layer, so an inherited reference cannot be validated there at all — it is preserved rather than deleted. Applied to both engines (mdl/backend/modelsdk and sdk/mpr), which had separate copies of the same defect.

Verification

End-to-end on a real 11.12.2 project carrying all three specialisation shapes at once — same-module ancestor, System.FileDocument, and System.User:

mx check  ->  The app contains: 0 errors.
describe  ->  grant Sec758.Editor on Sec758.Item (read (OwnField, SharedField));

Stored refs are Sec758.Item.OwnField + Sec758.Base.SharedField; Attachment gets 6 System.FileDocument entries; Employee gets 0 System.User entries.

All three guards mutation-checked — removing the chain walk, the System.User exclusion, or the reconciler's ownership check each reproduces the reported symptom. Full ./... suite green.

Repro script: mdl-examples/bug-tests/758-inherited-member-access.mdl.

Scope

This fixes mendixlabs#758 and the security half of the mendixlabs#765 umbrella. mendixlabs#765 also covers mendixlabs#703 (import/export mapping skips inherited attributes) — untouched here — and mendixlabs#451, whose declaring-entity rule the microflow path already implements via resolveAttributeInEntityHierarchy. EntityMembers is deliberately ctx-based and reusable, so mendixlabs#703 can adopt it.

Generalisable lesson (recorded in the symptom table)

When a post-write reconcile pass validates against a narrower model than the writer used, it will quietly undo correct writes. Check what runs after a write before concluding the writer is at fault — the grant code here was fixed first and appeared to change nothing.

Generated by Claude Code